<html><head>
      <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
   <title>1.&nbsp;Introduction to Spring Framework</title><link rel="stylesheet" href="css/stylesheet.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.74.0"><link rel="home" href="index.html" title="Reference Documentation"><link rel="up" href="spring-introduction.html" title="Part&nbsp;I.&nbsp;Overview of Spring Framework"><link rel="prev" href="spring-introduction.html" title="Part&nbsp;I.&nbsp;Overview of Spring Framework"><link rel="next" href="spring-whats-new.html" title="Part&nbsp;II.&nbsp;What's New in Spring 3"><!--Begin Google Analytics code--><script type="text/javascript">
			var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
			document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
		</script><script type="text/javascript">
			var pageTracker = _gat._getTracker("UA-2728886-3");
			pageTracker._setDomainName("none");
			pageTracker._setAllowLinker(true);
			pageTracker._trackPageview();
		</script><!--End Google Analytics code--></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">1.&nbsp;Introduction to Spring Framework</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="spring-introduction.html">Prev</a>&nbsp;</td><th width="60%" align="center">Part&nbsp;I.&nbsp;Overview of Spring Framework</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="spring-whats-new.html">Next</a></td></tr></table><hr></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="overview"></a>1.&nbsp;Introduction to Spring Framework</h2></div></div></div><p>Spring Framework is a Java platform that provides comprehensive
  infrastructure support for developing Java applications. Spring handles the
  infrastructure so you can focus on your application.</p><p>Spring enables you to build applications from &#8220;plain old Java objects&#8221;
  (POJOs) and to apply enterprise services non-invasively to POJOs. This
  capability applies to the Java SE programming model and to full and partial
  Java EE.</p><p>Examples of how you, as an application developer, can use the Spring
  platform advantage:</p><div class="itemizedlist"><ul type="disc"><li><p>Make a Java method execute in a database transaction without
      having to deal with transaction APIs.</p></li><li><p>Make a local Java method a remote procedure without having to deal
      with remote APIs.</p></li><li><p>Make a local Java method a management operation without having to
      deal with JMX APIs.</p></li><li><p>Make a local Java method a message handler without having to deal
      with JMS APIs.</p></li></ul></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="overview-dependency-injection"></a>1.1&nbsp;Dependency Injection and Inversion of Control</h2></div></div></div><div class="sidebar"><a name="background-ioc"></a><p class="title"><b>Background</b></p><p>&#8220;<span class="quote"><span class="emphasis"><em>The question is, what aspect of control are
      [they] inverting?</em></span></span>&#8221; Martin Fowler posed this question
      about Inversion of Control (IoC) on his site in 2004. Fowler suggested
      renaming the principle to make it more self-explanatory and came up with
      <em class="firstterm">Dependency Injection</em>.</p><p>For insight into IoC and DI, refer to Fowler's article at <a class="ulink" href="http://martinfowler.com/articles/injection.html" target="_top">http://martinfowler.com/articles/injection.html</a>.</p></div><p>Java applications -- a loose term that runs the gamut from
    constrained applets to n-tier server-side enterprise applications --
    typically consist of objects that collaborate to form the application
    proper. Thus the objects in an application have
    <span class="emphasis"><em>dependencies</em></span> on each other.</p><p>Although the Java platform provides a wealth of application
    development functionality, it lacks the means to organize the basic
    building blocks into a coherent whole, leaving that task to architects and
    developers. True, you can use design patterns such as
    <em class="firstterm">Factory</em>, <em class="firstterm">Abstract Factory</em>,
    <em class="firstterm">Builder</em>, <em class="firstterm">Decorator</em>, and
    <em class="firstterm">Service Locator</em> to compose the various classes and
    object instances that make up an application. However, these patterns are
    simply that: best practices given a name, with a description of what the
    pattern does, where to apply it, the problems it addresses, and so forth.
    Patterns are formalized best practices that <span class="emphasis"><em>you must implement
    yourself</em></span> in your application.</p><p>The Spring Framework <span class="emphasis"><em>Inversion of Control</em></span> (IoC)
    component addresses this concern by providing a formalized means of
    composing disparate components into a fully working application ready for
    use. The
    Spring Framework codifies formalized design patterns as first-class
    objects that you can integrate into your own application(s). Numerous
    organizations and institutions use the Spring Framework in this manner to
    engineer robust, <span class="emphasis"><em>maintainable</em></span> applications.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="overview-modules"></a>1.2&nbsp;Modules</h2></div></div></div><p>The Spring Framework consists of features organized into about 20
    modules. These modules are grouped into Core Container, Data
    Access/Integration, Web, AOP (Aspect Oriented Programming),
    Instrumentation, and Test, as shown in the following diagram.</p><div class="mediaobject" align="center"><img src="images/spring-overview.png" align="middle"><div class="caption"><p>Overview of the Spring Framework</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e281"></a>1.2.1&nbsp;Core Container</h3></div></div></div><p>The <a class="link" href="beans.html#beans-introduction" title="4.1&nbsp;Introduction to the Spring IoC container and beans"><span class="emphasis"><em>Core
      Container</em></span></a> consists of the Core, Beans, Context, and
      Expression Language modules.</p><p>The <a class="link" href="beans.html#beans-introduction" title="4.1&nbsp;Introduction to the Spring IoC container and beans"><span class="emphasis"><em>Core and
      Beans</em></span></a> modules provide the fundamental parts of the
      framework, including the IoC and Dependency Injection features. The
      <code class="classname">BeanFactory</code> is a sophisticated implementation of
      the factory pattern. It removes the need for programmatic singletons and
      allows you to decouple the configuration and specification of
      dependencies from your actual program logic.</p><p>The <a class="link" href="beans.html#context-introduction" title="4.14&nbsp;Additional Capabilities of the ApplicationContext"><span class="emphasis"><em>Context</em></span></a>
      module builds on the solid base provided by the <a class="link" href="beans.html#beans-introduction" title="4.1&nbsp;Introduction to the Spring IoC container and beans"><span class="emphasis"><em>Core and Beans</em></span></a>
      modules: it is a means to access objects in a framework-style manner
      that is similar to a JNDI registry. The Context module inherits its
      features from the Beans module and adds support for internationalization
      (using, for example, resource bundles), event-propagation,
      resource-loading, and the transparent creation of contexts by, for
      example, a servlet container. The Context module also supports Java EE
      features such as EJB, JMX ,and basic remoting. The
      <code class="classname">ApplicationContext</code> interface is the focal point
      of the Context module.</p><p>The <a class="link" href="expressions.html" title="7.&nbsp;Spring Expression Language (SpEL)"><span class="emphasis"><em>Expression
      Language</em></span></a> module provides
      a powerful expression language for querying and manipulating an object
      graph at runtime. It is an extension of the unified expression language
      (unified EL) as specified in the JSP 2.1 specification. The language
      supports setting and getting property values, property assignment,
      method invocation, accessing the context of arrays, collections and
      indexers, logical and arithmetic operators, named variables, and
      retrieval of objects by name from Spring's IoC container. It also
      supports list projection and selection as well as common list
      aggregations.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e320"></a>1.2.2&nbsp;Data Access/Integration</h3></div></div></div><p>The <span class="emphasis"><em>Data Access/Integration</em></span> layer consists of
      the JDBC, ORM, OXM, JMS and Transaction modules.</p><p>The <a class="link" href="jdbc.html#jdbc-introduction" title="13.1&nbsp;Introduction to Spring Framework JDBC">JDBC</a> module provides
      a JDBC-abstraction layer that removes the need to do tedious JDBC coding
      and parsing of database-vendor specific error codes.</p><p>The <a class="link" href="orm.html#orm-introduction" title="14.1&nbsp;Introduction to ORM with Spring"><span class="emphasis"><em>ORM</em></span></a> module
      provides integration layers for popular object-relational mapping APIs,
      including <a class="link" href="orm.html#orm-jpa" title="14.5&nbsp;JPA">JPA</a>, <a class="link" href="orm.html#orm-jdo" title="14.4&nbsp;JDO">JDO</a>, <a class="link" href="orm.html#orm-hibernate" title="14.3&nbsp;Hibernate">Hibernate</a>, and <a class="link" href="orm.html#orm-ibatis" title="14.6&nbsp;iBATIS SQL Maps">iBatis</a>. Using the ORM package you can use
      all of these O/R-mapping frameworks in combination with all of the other
      features Spring offers, such as the simple declarative transaction
      management feature mentioned previously.</p><p>The <a class="link" href="oxm.html" title="15.&nbsp;Marshalling XML using O/X Mappers">OXM</a> module provides an abstraction
      layer that supports Object/XML mapping implementations for JAXB, Castor,
      XMLBeans, JiBX and XStream.</p><p>The Java Messaging Service (<a class="link" href="jms.html" title="22.&nbsp;JMS (Java Message Service)">JMS</a>) module
      contains features for producing and consuming messages.</p><p>The <a class="link" href="transaction.html" title="11.&nbsp;Transaction Management">Transaction</a> module supports
      programmatic and declarative transaction management for classes that
      implement special interfaces and for <span class="emphasis"><em>all your POJOs (plain old
      Java objects)</em></span>.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e369"></a>1.2.3&nbsp;Web</h3></div></div></div><p>The <span class="emphasis"><em>Web</em></span> layer consists of the Web,
      Web-Servlet, Web-Struts, and Web-Portlet modules.</p><p>Spring's <span class="emphasis"><em>Web</em></span> module provides basic
      web-oriented integration features such as multipart file-upload
      functionality and the initialization of the IoC container using servlet
      listeners and a web-oriented application context. It also contains the
      web-related parts of Spring's remoting support.</p><p>The <span class="emphasis"><em>Web-Servlet</em></span> module contains Spring's
      model-view-controller (<a class="link" href="mvc.html#mvc-introduction" title="16.1&nbsp;Introduction to Spring Web MVC framework"><span class="emphasis"><em>MVC</em></span></a>)
      implementation for web applications. Spring's MVC framework provides a
      clean separation between domain model code and web forms, and integrates
      with all the other features of the Spring Framework.</p><p>The <span class="emphasis"><em>Web-Struts</em></span> module contains the support
      classes for integrating a classic Struts web tier within a Spring
      application. Note that this support is now deprecated as of Spring 3.0.
      Consider migrating your application to Struts 2.0 and its Spring
      integration or to a Spring MVC solution.</p><p>The <span class="emphasis"><em>Web-Portlet</em></span> module provides the MVC
      implementation to be used in a portlet environment and mirrors the
      functionality of Web-Servlet module.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e405"></a>1.2.4&nbsp;AOP and Instrumentation</h3></div></div></div><p>Spring's <a class="link" href="aop.html#aop-introduction" title="8.1&nbsp;Introduction"><span class="emphasis"><em>AOP</em></span></a> module
      provides an <span class="emphasis"><em>AOP Alliance</em></span>-compliant aspect-oriented
      programming implementation allowing you to define, for example,
      method-interceptors and pointcuts to cleanly decouple code that
      implements functionality that should be separated. Using source-level
      metadata functionality, you can also incorporate behavioral information
      into your code, in a manner similar to that of .NET attributes.</p><p>The separate <span class="emphasis"><em>Aspects</em></span> module provides
      integration with AspectJ.</p><p>The <span class="emphasis"><em>Instrumentation</em></span> module provides class
      instrumentation support and classloader implementations to be used in
      certain application servers.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e428"></a>1.2.5&nbsp;Test</h3></div></div></div><p>The <span class="emphasis"><em>Test</em></span> module supports the testing of
      Spring components with JUnit or TestNG. It provides consistent loading
      of Spring ApplicationContexts and caching of those contexts. It also
      provides mock objects that you can use to test your code in
      isolation.</p></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="overview-usagescenarios"></a>1.3&nbsp;Usage scenarios</h2></div></div></div><p>The building blocks described previously make Spring a logical
    choice in many scenarios, from applets to full-fledged enterprise
    applications that use Spring's transaction management functionality and
    web framework integration.</p><div class="mediaobject" align="center"><img src="images/overview-full.png" align="middle"><div class="caption"><p>Typical full-fledged Spring web
        application</p></div></div><p>Spring's <a class="link" href="transaction.html#transaction-declarative" title="11.5&nbsp;Declarative transaction management">declarative
    transaction management features</a> make the web application fully
    transactional, just as it would be if you used EJB container-managed
    transactions. All your custom business logic can be implemented with
    simple POJOs and managed by Spring's IoC container. Additional services
    include support for sending email and validation that is independent of
    the web layer, which lets you choose where to execute validation rules.
    Spring's ORM support is integrated with JPA, Hibernate, JDO and iBatis;
    for example, when using Hibernate, you can continue to use your existing
    mapping files and standard Hibernate
    <code class="interfacename">SessionFactory</code> configuration. Form
    controllers seamlessly integrate the web-layer with the domain model,
    removing the need for <code class="classname">ActionForms</code> or other classes
    that transform HTTP parameters to values for your domain model.</p><div class="mediaobject" align="center"><img src="images/overview-thirdparty-web.png" align="middle"><div class="caption"><p>Spring middle-tier using a third-party web
        framework</p></div></div><p>Sometimes circumstances do not allow you to completely switch to a
    different framework. The Spring Framework does <span class="emphasis"><em>not</em></span>
    force you to use everything within it; it is not an
    <span class="emphasis"><em>all-or-nothing</em></span> solution. Existing front-ends built
    with WebWork, Struts, Tapestry, or other UI frameworks can be integrated
    with a Spring-based middle-tier, which allows you to use Spring
    transaction features. You simply need to wire up your business logic using
    an <code class="classname">ApplicationContext</code> and use a
    <code class="classname">WebApplicationContext </code>to integrate your web
    layer.</p><div class="mediaobject" align="center"><img src="images/overview-remoting.png" align="middle"><div class="caption"><p>Remoting usage scenario</p></div></div><p>When you need to access existing code through web services, you can
    use Spring's <code class="literal">Hessian-</code>, <code class="literal">Burlap-</code>,
    <code class="literal">Rmi-</code> or <code class="classname">JaxRpcProxyFactory</code>
    classes. Enabling remote access to existing applications is not
    difficult.</p><div class="mediaobject" align="center"><img src="images/overview-ejb.png" align="middle"><div class="caption"><p>EJBs - Wrapping existing POJOs</p></div></div><p>The Spring Framework also provides an <a class="link" href="ejb.html" title="21.&nbsp;Enterprise JavaBeans (EJB) integration">access and
    abstraction layer</a> for Enterprise JavaBeans, enabling you to reuse
    your existing POJOs and wrap them in stateless session beans for use in
    scalable, fail-safe web applications that might need declarative
    security.</p><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="dependency-management"></a>1.3.1&nbsp;Dependency Management and Naming Conventions</h3></div></div></div><p>Dependency management and dependency injection are different
      things. To get those nice features of Spring into your application (like
      dependency injection) you need to assemble all the libraries needed (jar
      files) and get them onto your classpath at runtime, and possibly at
      compile time. These dependencies are not virtual components that are
      injected, but physical resources in a file system (typically). The
      process of dependency management involves locating those resources,
      storing them and adding them to classpaths. Dependencies can be direct
      (e.g. my application depends on Spring at runtime), or indirect (e.g. my
      application depends on <code class="code">commons-dbcp</code> which depends on
      <code class="code">commons-pool</code>). The indirect dependencies are also known as
      "transitive" and it is those dependencies that are hardest to identify
      and manage.</p><p>If you are going to use Spring you need to get a copy of the jar
      libraries that comprise the pieces of Spring that you need. To make this
      easier Spring is packaged as a set of modules that separate the
      dependencies as much as possible, so for example if you don't want to
      write a web application you don't need the spring-web modules. To refer
      to Spring library modules in this guide we use a shorthand naming
      convention <code class="code">spring-*</code> or <code class="code">spring-*.jar,</code> where "*"
      represents the short name for the module (e.g. <code class="code">spring-core</code>,
      <code class="code">spring-webmvc</code>, <code class="code">spring-jms</code>, etc.). The actual
      jar file name that you use may be in this form (see below) or it may
      not, and normally it also has a version number in the file name (e.g.
      <code class="code">spring-core-3.0.0.RELEASE.jar</code>).</p><p>In general, Spring publishes its artifacts to four different
      places:</p><div class="itemizedlist"><ul type="disc"><li><p>On the community download site <a class="ulink" href="http://www.springsource.org/downloads/community" target="_top">http://www.springsource.org/downloads/community</a>.
            Here you find all the Spring jars bundled together into a zip file
            for easy download. The names of the jars here since version 3.0
            are in the form
            <code class="code">org.springframework.*-&lt;version&gt;.jar</code>.</p></li><li><p>Maven Central, which is the default repository that Maven
            queries, and does not require any special configuration to use.
            Many of the common libraries that Spring depends on also are
            available from Maven Central and a large section of the Spring
            community uses Maven for dependency management, so this is
            convenient for them. The names of the jars here are in the form
            <code class="code">spring-*-&lt;version&gt;.jar</code> and the Maven groupId is
            <code class="code">org.springframework</code>.</p></li><li><p>The Enterprise Bundle Repository (EBR), which is run by
            SpringSource and also hosts all the libraries that integrate with
            Spring. Both Maven and Ivy repositories are available here for all
            Spring jars and their dependencies, plus a large number of other
            common libraries that people use in applications with Spring. Both
            full releases and also milestones and development snapshots are
            deployed here. The names of the jar files are in the same form as
            the community download
            (<code class="code">org.springframework.*-&lt;version&gt;.jar</code>), and the
            dependencies are also in this "long" form, with external libraries
            (not from SpringSource) having the prefix
            <code class="code">com.springsource</code>. See the <a class="ulink" href="http://www.springsource.com/repository/app/faq" target="_top">FAQ</a>
            for more information.</p></li><li><p>In a public Maven repository hosted on Amazon S3 for
            development snapshots and milestone releases (a copy of the final
            releases is also held here). The jar file names are in the same
            form as Maven Central, so this is a useful place to get
            development versions of Spring to use with other libraries depoyed
            in Maven Central.</p></li></ul></div><p>So the first thing you need to decide is how to manage your
      dependencies: most people use an automated system like Maven or Ivy, but
      you can also do it manually by downloading all the jars yourself. When
      obtaining Spring with Maven or Ivy you have then to decide which place
      you'll get it from. In general, if you care about OSGi, use the EBR,
      since it houses OSGi compatible artifacts for all of Spring's
      dependencies, such as Hibernate and Freemarker. If OSGi does not matter
      to you, either place works, though there are some pros and cons between
      them. In general, pick one place or the other for your project; do not
      mix them. This is particularly important since EBR artifacts necessarily
      use a different naming convention than Maven Central artifacts.</p><div class="table"><a name="d0e591"></a><p class="title"><b>Table&nbsp;1.1.&nbsp;Comparison of Maven Central and SpringSource EBR
          Repositories</b></p><div class="table-contents"><table summary="Comparison of Maven Central and SpringSource EBR&#xA;          Repositories" style="border-collapse: collapse;border-top: 1.0pt solid ; border-bottom: 1.0pt solid ; border-left: 1.0pt solid ; border-right: 1.0pt solid ; "><colgroup><col><col><col></colgroup><thead><tr><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Feature</th><th style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Maven Central</th><th style="border-bottom: 1.0pt solid ; ">EBR</th></tr></thead><tbody><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">OSGi Compatible</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Not explicit</td><td style="border-bottom: 1.0pt solid ; ">Yes</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Number of Artifacts</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Tens of thousands; all kinds</td><td style="border-bottom: 1.0pt solid ; ">Hundreds; those that Spring integrates with</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Consistent Naming Conventions</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">No</td><td style="border-bottom: 1.0pt solid ; ">Yes</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Naming Convention: GroupId</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Varies. Newer artifacts often use domain name, e.g.
                org.slf4j. Older ones often just use the artifact name, e.g.
                log4j.</td><td style="border-bottom: 1.0pt solid ; ">Domain name of origin or main package root, e.g.
                org.springframework</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Naming Convention: ArtifactId</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Varies. Generally the project or module name, using a
                hyphen "-" separator, e.g. spring-core, logj4.</td><td style="border-bottom: 1.0pt solid ; ">Bundle Symbolic Name, derived from the main package
                root, e.g. org.springframework.beans. If the jar had to be
                patched to ensure OSGi compliance then com.springsource is
                appended, e.g. com.springsource.org.apache.log4j</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Naming Convention: Version</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Varies. Many new artifacts use m.m.m or m.m.m.X (with
                m=digit, X=text). Older ones use m.m. Some neither. Ordering
                is defined but not often relied on, so not strictly
                reliable.</td><td style="border-bottom: 1.0pt solid ; ">OSGi version number m.m.m.X, e.g. 3.0.0.RC3. The text
                qualifier imposes alphabetic ordering on versions with the
                same numeric values.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Publishing</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Usually automatic via rsync or source control updates.
                Project authors can upload individual jars to JIRA.</td><td style="border-bottom: 1.0pt solid ; ">Manual (JIRA processed by SpringSource)</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Quality Assurance</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">By policy. Accuracy is responsibility of
                authors.</td><td style="border-bottom: 1.0pt solid ; ">Extensive for OSGi manifest, Maven POM and Ivy
                metadata. QA performed by Spring team.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Hosting</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Contegix. Funded by Sonatype with several
                mirrors.</td><td style="border-bottom: 1.0pt solid ; ">S3 funded by SpringSource.</td></tr><tr><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Search Utilities</td><td style="border-right: 1.0pt solid ; border-bottom: 1.0pt solid ; ">Various</td><td style="border-bottom: 1.0pt solid ; "><a class="ulink" href="http://www.springsource.com/repository" target="_top">http://www.springsource.com/repository</a></td></tr><tr><td style="border-right: 1.0pt solid ; ">Integration with SpringSource Tools</td><td style="border-right: 1.0pt solid ; ">Integration through STS with Maven dependency
                management</td><td style="">Extensive integration through STS with Maven, Roo,
                CloudFoundry</td></tr></tbody></table></div></div><p><br class="table-break"></p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="d0e682"></a>1.3.1.1&nbsp;Spring Dependencies and Depending on Spring</h4></div></div></div><p>Although Spring provides integration and support for a huge
        range of enterprise and other external tools, it intentionally keeps
        its mandatory dependencies to an absolute minimum: you shouldn't have
        to locate and download (even automatically) a large number of jar
        libraries in order to use Spring for simple use cases. For basic
        dependency injection there is only one mandatory external dependency,
        and that is for logging (see below for a more detailed description of
        logging options).</p><p>Next we outline the basic steps needed to configure an
        application that depends on Spring, first with Maven and then with
        Ivy. In all cases, if anything is unclear, refer to the documentation
        of your dependency management system, or look at some sample code -
        Spring itself uses Ivy to manage dependencies when it is building, and
        our samples mostly use Maven.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="d0e689"></a>1.3.1.2&nbsp;Maven Dependency Management</h4></div></div></div><p>If you are using Maven for dependency management you don't even
        need to supply the logging dependency explicitly. For example, to
        create an application context and use dependency injection to
        configure an application, your Maven dependencies will look like
        this:</p><pre class="programlisting">&lt;dependencies&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;org.springframework&lt;/groupId&gt;
      &lt;artifactId&gt;spring-context&lt;/artifactId&gt;
      &lt;version&gt;3.0.0.RELEASE&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
   &lt;/dependency&gt;
&lt;/dependencies&gt; </pre><p>That's it. Note the scope can be declared as runtime if you
        don't need to compile against Spring APIs, which is typically the case
        for basic dependency injection use cases.</p><p>We used the Maven Central naming conventions in the example
        above, so that works with Maven Central or the SpringSource S3 Maven
        repository. To use the S3 Maven repository (e.g. for milestones or
        developer snaphots), you need to specify the repository location in
        your Maven configuration. For full releases:</p><pre class="programlisting">&lt;repositories&gt;
   &lt;repository&gt;
      &lt;id&gt;com.springsource.repository.maven.release&lt;/id&gt;
      &lt;url&gt;http://maven.springframework.org/release/&lt;/url&gt;
      &lt;snapshots&gt;&lt;enabled&gt;false&lt;/enabled&gt;&lt;/snapshots&gt;
   &lt;/repository&gt;
&lt;/repositories&gt;</pre><p>For milestones:</p><pre class="programlisting">&lt;repositories&gt;
   &lt;repository&gt;
      &lt;id&gt;com.springsource.repository.maven.milestone&lt;/id&gt;
      &lt;url&gt;http://maven.springframework.org/milestone/&lt;/url&gt;
      &lt;snapshots&gt;&lt;enabled&gt;false&lt;/enabled&gt;&lt;/snapshots&gt;
   &lt;/repository&gt;
&lt;/repositories&gt;</pre><p>And for snapshots:</p><pre class="programlisting">&lt;repositories&gt;
   &lt;repository&gt;
      &lt;id&gt;com.springsource.repository.maven.snapshot&lt;/id&gt;
      &lt;url&gt;http://maven.springframework.org/snapshot/&lt;/url&gt;
      &lt;snapshots&gt;&lt;enabled&gt;true&lt;/enabled&gt;&lt;/snapshots&gt;
   &lt;/repository&gt;
&lt;/repositories&gt;</pre><p>To use the SpringSource EBR you would need to use a different
        naming convention for the dependencies. The names are usually easy to
        guess, e.g. in this case it is:</p><pre class="programlisting">&lt;dependencies&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;org.springframework&lt;/groupId&gt;
      &lt;artifactId&gt;org.springframework.context&lt;/artifactId&gt;
      &lt;version&gt;3.0.0.RELEASE&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
   &lt;/dependency&gt;
&lt;/dependencies&gt;</pre><p>You also need to declare the location of the repository
        explicitly (only the URL is important):</p><pre class="programlisting">&lt;repositories&gt;
   &lt;repository&gt;
      &lt;id&gt;com.springsource.repository.bundles.release&lt;/id&gt;
      &lt;url&gt;http://repository.springsource.com/maven/bundles/release/&lt;/url&gt;
   &lt;/repository&gt;
&lt;/repositories&gt;</pre><p>If you are managing your dependencies by hand, the URL in the
        repository declaration above is not browseable, but there is a user
        interface at <a class="ulink" href="http://www.springsource.com/repository" target="_top">http://www.springsource.com/repository</a>
        that can be used to search for and download dependencies. It also has
        handy snippets of Maven and Ivy configuration that you can copy and
        paste if you are using those tools.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="d0e724"></a>1.3.1.3&nbsp;Ivy Dependency Management</h4></div></div></div><p>If you prefer to use <a class="ulink" href="http://ant.apache.org/ivy" target="_top">Ivy</a> to manage dependencies
        then there are similar names and configuration options. </p><p>To configure Ivy to point to the SpringSource EBR add the
        following resolvers to your
        <code class="filename">ivysettings.xml</code>:</p><pre class="programlisting">&lt;resolvers&gt;
  
  &lt;url name="com.springsource.repository.bundles.release"&gt;

    &lt;ivy pattern="http://repository.springsource.com/ivy/bundles/release/
      [organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /&gt;
    &lt;artifact pattern="http://repository.springsource.com/ivy/bundles/release/
      [organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /&gt;

  &lt;/url&gt;

  &lt;url name="com.springsource.repository.bundles.external"&gt;

    &lt;ivy pattern="http://repository.springsource.com/ivy/bundles/external/
       [organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /&gt;
    &lt;artifact pattern="http://repository.springsource.com/ivy/bundles/external/
       [organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /&gt; 

  &lt;/url&gt;

&lt;/resolvers&gt;</pre><p>The XML above is not valid because the lines are too long - if
        you copy-paste then remove the extra line endings in the middle of the
        url patterns.</p><p>Once Ivy is configured to look in the EBR adding a dependency is
        easy. Simply pull up the details page for the bundle in question in
        the repository browser and you'll find an Ivy snippet ready for you to
        include in your dependencies section. For example (in
        <code class="filename">ivy.xml</code>): </p><pre class="programlisting">&lt;dependency org="org.springframework" 
      name="org.springframework.core" rev="3.0.0.RELEASE" conf="compile-&gt;runtime"/&gt;</pre></div></div><div class="section" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="d0e748"></a>1.3.2&nbsp;Logging</h3></div></div></div><p>Logging is a very important dependency for Spring because a) it is
      the only mandatory external dependency, b) everyone likes to see some
      output from the tools they are using, and c) Spring integrates with lots
      of other tools all of which have also made a choice of logging
      dependency. One of the goals of an application developer is often to
      have unified logging configured in a central place for the whole
      application, including all external components. This is more difficult
      than it might have been since there are so many choices of logging
      framework.</p><p>The mandatory logging dependency in Spring is the Jakarta Commons
      Logging API (JCL). We compile against JCL and we also make JCL
      <code class="classname">Log</code> objects visible for classes that extend the
      Spring Framework. It's important to users that all versions of Spring
      use the same logging library: migration is easy because backwards
      compatibility is preserved even with applications that extend Spring.
      The way we do this is to make one of the modules in Spring depend
      explicitly on <code class="code">commons-logging</code> (the canonical implementation
      of JCL), and then make all the other modules depend on that at compile
      time. If you are using Maven for example, and wondering where you picked
      up the dependency on <code class="code">commons-logging</code>, then it is from
      Spring and specifically from the central module called
      <code class="code">spring-core</code>.</p><p>The nice thing about <code class="code">commons-logging</code> is that you
      don't need anything else to make your application work. It has a runtime
      discovery algorithm that looks for other logging frameworks in well
      known places on the classpath and uses one that it thinks is appropriate
      (or you can tell it which one if you need to). If nothing else is
      available you get pretty nice looking logs just from the JDK
      (java.util.logging or JUL for short). You should find that your Spring
      application works and logs happily to the console out of the box in most
      situations, and that's important.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="d0e772"></a>1.3.2.1&nbsp;Not Using Commons Logging</h4></div></div></div><p>Unfortunately, the runtime discovery algorithm in
        <code class="code">commons-logging</code>, while convenient for the end-user, is
        problematic. If we could turn back the clock and start Spring now
        as a new project it would use a different logging dependency. The
        first choice would probably be the Simple Logging Facade for Java (<a class="ulink" href="http://www.slf4j.org" target="_top">SLF4J</a>), which is also used by a lot
        of other tools that people use with Spring inside their
        applications.</p><p>Switching off <code class="code">commons-logging</code> is easy: just make
        sure it isn't on the classpath at runtime. In Maven terms you exclude
        the dependency, and because of the way that the Spring dependencies
        are declared, you only have to do that once.</p><pre class="programlisting">&lt;dependencies&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;org.springframework&lt;/groupId&gt;
      &lt;artifactId&gt;spring-context&lt;/artifactId&gt;
      &lt;version&gt;3.0.0.RELEASE&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
      &lt;exclusions&gt;
         &lt;exclusion&gt;
            &lt;groupId&gt;commons-logging&lt;/groupId&gt;
            &lt;artifactId&gt;commons-logging&lt;/artifactId&gt;
         &lt;/exclusion&gt;
      &lt;/exclusions&gt;
   &lt;/dependency&gt;
&lt;/dependencies&gt; </pre><p>Now this application is probably broken because there is no
        implementation of the JCL API on the classpath, so to fix it a new one
        has to be provided. In the next section we show you how to provide an
        alternative implementation of JCL using SLF4J as an example.</p></div><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="d0e792"></a>1.3.2.2&nbsp;Using SLF4J</h4></div></div></div></div><p>SLF4J is a cleaner dependency and more efficient at runtime than
      <code class="code">commons-logging</code> because it uses compile-time bindings
      instead of runtime discovery of the other logging frameworks it
      integrates. This also means that you have to be more explicit about what
      you want to happen at runtime, and declare it or configure it
      accordingly. SLF4J provides bindings to many common logging frameworks,
      so you can usually choose one that you already use, and bind to that for
      configuration and management.</p><p>SLF4J provides bindings to many common logging frameworks,
      including JCL, and it also does the reverse: bridges between other
      logging frameworks and itself. So to use SLF4J with Spring you need to
      replace the <code class="code">commons-logging</code> dependency with the SLF4J-JCL
      bridge. Once you have done that then logging calls from within Spring
      will be translated into logging calls to the SLF4J API, so if other
      libraries in your application use that API, then you have a single place
      to configure and manage logging.</p><p>A common choice might be to bridge Spring to SLF4J, and then
      provide explicit binding from SLF4J to Log4J. You need to supply 4
      dependencies (and exclude the existing <code class="code">commons-logging</code>):
      the bridge, the SLF4J API, the binding to Log4J, and the Log4J
      implementation itself. In Maven you would do that like this</p><pre class="programlisting">&lt;dependencies&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;org.springframework&lt;/groupId&gt;
      &lt;artifactId&gt;spring-context&lt;/artifactId&gt;
      &lt;version&gt;3.0.0.RELEASE&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
      &lt;exclusions&gt;
         &lt;exclusion&gt;
            &lt;groupId&gt;commons-logging&lt;/groupId&gt;
            &lt;artifactId&gt;commons-logging&lt;/artifactId&gt;
         &lt;/exclusion&gt;
      &lt;/exclusions&gt;
   &lt;/dependency&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;org.slf4j&lt;/groupId&gt;
      &lt;artifactId&gt;jcl-over-slf4j&lt;/artifactId&gt;
      &lt;version&gt;1.5.8&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
   &lt;/dependency&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;org.slf4j&lt;/groupId&gt;
      &lt;artifactId&gt;slf4j-api&lt;/artifactId&gt;
      &lt;version&gt;1.5.8&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
   &lt;/dependency&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;org.slf4j&lt;/groupId&gt;
      &lt;artifactId&gt;slf4j-log4j12&lt;/artifactId&gt;
      &lt;version&gt;1.5.8&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
   &lt;/dependency&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;log4j&lt;/groupId&gt;
      &lt;artifactId&gt;log4j&lt;/artifactId&gt;
      &lt;version&gt;1.2.14&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
   &lt;/dependency&gt;
&lt;/dependencies&gt; </pre><p>That might seem like a lot of dependencies just to get some
      logging. Well it is, but it <span class="emphasis"><em>is</em></span> optional, and it
      should behave better than the vanilla <code class="code">commons-logging</code> with
      respect to classloader issues, notably if you are in a strict container
      like an OSGi platform. Allegedly there is also a performance benefit
      because the bindings are at compile-time not runtime.</p><p>A more common choice amongst SLF4J users, which uses fewer steps
      and generates fewer dependencies, is to bind directly to <a class="ulink" href="http://logback.qos.ch" target="_top">Logback</a>. This removes the extra
      binding step because Logback implements SLF4J directly, so you only need
      to depend on two libaries not four (<code class="code">jcl-over-slf4j</code> and
      <code class="code">logback</code>). If you do that you might also need to exlude the
      slf4j-api dependency from other external dependencies (not Spring),
      because you only want one version of that API on the classpath.</p><div class="section" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="d0e831"></a>1.3.2.3&nbsp;Using Log4J</h4></div></div></div><p>Many people use <a class="ulink" href="http://logging.apache.org/log4j" target="_top">Log4j</a> as a logging
        framework for configuration and management purposes. It's efficient
        and well-established, and in fact it's what we use at runtime when we
        build and test Spring. Spring also provides some utilities for
        configuring and initializing Log4j, so it has an optional compile-time
        dependency on Log4j in some modules.</p><p>To make Log4j work with the default JCL dependency
        (<code class="code">commons-logging</code>) all you need to do is put Log4j on the
        classpath, and provide it with a configuration file
        (<code class="code">log4j.properties</code> or <code class="code">log4j.xml</code> in the root
        of the classpath). So for Maven users this is your dependency
        declaration:</p><pre class="programlisting">&lt;dependencies&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;org.springframework&lt;/groupId&gt;
      &lt;artifactId&gt;spring-context&lt;/artifactId&gt;
      &lt;version&gt;3.0.0.RELEASE&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
   &lt;/dependency&gt;
   &lt;dependency&gt;
      &lt;groupId&gt;log4j&lt;/groupId&gt;
      &lt;artifactId&gt;log4j&lt;/artifactId&gt;
      &lt;version&gt;1.2.14&lt;/version&gt;
      &lt;scope&gt;runtime&lt;/scope&gt;
   &lt;/dependency&gt;
&lt;/dependencies&gt; </pre><p>And here's a sample log4j.properties for logging to the
        console:</p><pre class="programlisting">log4j.rootCategory=INFO, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c{2}:%L - %m%n

log4j.category.org.springframework.beans.factory=DEBUG</pre><div class="section" lang="en"><div class="titlepage"><div><div><h5 class="title"><a name="d0e856"></a>Runtime Containers with Native JCL</h5></div></div></div><p>Many people run their Spring applications in a container that
          itself provides an implementation of JCL. IBM Websphere Application
          Server (WAS) is the archetype. This often causes problems, and
          unfortunately there is no silver bullet solution; simply excluding
          <code class="code">commons-logging</code> from your application is not enough in
          most situations.</p><p>To be clear about this: the problems reported are usually not
          with JCL per se, or even with <code class="code">commons-logging</code>: rather
          they are to do with binding <code class="code">commons-logging</code> to another
          framework (often Log4J). This can fail because
          <code class="code">commons-logging</code> changed the way they do the runtime
          discovery in between the older versions (1.0) found in some
          containers and the modern versions that most people use now (1.1).
          Spring does not use any unusual parts of the JCL API, so nothing
          breaks there, but as soon as Spring or your application tries to do
          any logging you can find that the bindings to Log4J are not
          working.</p><p>In such cases with WAS the easiest thing to do is to invert
          the class loader hierarchy (IBM calls it "parent last") so that the
          application controls the JCL dependency, not the container. That
          option isn't always open, but there are plenty of other suggestions
          in the public domain for alternative approaches, and your mileage
          may vary depending on the exact version and feature set of the
          container.</p></div></div></div></div></div><!--Begin LoopFuse code--><script src="http://loopfuse.net/webrecorder/js/listen.js" type="text/javascript"></script><script type="text/javascript">
			_lf_cid = "LF_48be82fa";
			_lf_remora();
		</script><!--End LoopFuse code--><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="spring-introduction.html">Prev</a>&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="spring-introduction.html">Up</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="spring-whats-new.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Part&nbsp;I.&nbsp;Overview of Spring Framework&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top">&nbsp;Part&nbsp;II.&nbsp;What's New in Spring 3</td></tr></table></div></body></html>